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ARPANET, the Defense Data Network, 
and Internet 


Introduction 


In 1968, the Advanced Research Projects Agency (ARPA) of the US. Depart¬ 
ment of Defense initiated the funding for a research and development project in 
packet switching that has had profound effects on computer communications 
throughout the world. The initial project was called the ARPA Computer Net¬ 
work or ARPANET. Its first packet switches were installed in 1969, and it grew to 
contain almost 60 sites by July 1975, when it was turned over to the Defense 
Communications Agency as an operational service system. The network contin¬ 
ued to grow for several years until it was selected in 1982 to be the foundation of 
the Defense Data Network (DDN), a successor to the Autodin system as the 
common user network of the Department of Defense. In support of this new 
role, the network was split in two; the smaller network, which retained the 
ARPANET name, supports research uses, whereas the larger piece, MILNET, 
provides service to the military. 

In addition to providing direct communications services to research computer 
centers, ARPANET has served in a role of equal importance as the backbone 
and intellectual focus of Internet since 1983. Internet is a worldwide interconnec¬ 
tion of independent networks that facilitates and supports the collaboration of 
academic, government, and industrial researchers. Many of the networks that 
are part of Internet were built by ARPA (now called DARPA—the Defense 
Advanced Research Projects Agency), and for many years ARPANET was at the 
center of Internet. 


The Decision to Build ARPANET 

The MiS^IOs Technical Environment 

In the mid-1960s, computer usage had become widespread; tens of thousands of 
small, single-user computers and large, batch-processing computers were in use 
within the military and the world at large. These computers were made by many 
different manufacturers, such as IBM, Honeywell, CDC, Digital, Univac, SDS, 
and Burroughs. In general, each manufacturer offered several different lines of 
computers, but no common operating system was in use by a single manufactur¬ 
er, much less by multiple manufacturers. In fact, there were few common data 
formats, except at the lowest level (e.g., 6-bit characters packed at standard 
densities on magnetic tapes), or data communications formats (e.g., 5-bit Tele¬ 
type Baudot codes). In those cases where there was communication between 
compatible computers —computers of the same type from the same vendor—the 
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most common communication method was physical movement of magnetic 
tapes, magnetic disks, punched cards, or even paper tape. 

A number of interactive transaction processing systems existed, particularly 
in special industry applications such as airline reservation systems. These systems 
typically communicated from terminals to central computers by the transmission 
of individual characters or single lines of characters through hierarchies of time- 
division multiplexors and terminal cluster controllers. It was usual for separate 
central computer and terminal telecommunications networks to be used for sepa¬ 
rate applications within a single institution —for example, one for computer 
telecommunications systems for reservations and another for financial reporting 
within an airline. Most often, these telecommunications systems were specific to 
a vendor or even a computer type. Time sharing had been invented recently, but 
few institutions had their own time-sharing computers; more often, users ac¬ 
cessed time-sharing computer service bureaus that used telecommunications net¬ 
works similar to those used in transaction processing systems. 

Terminal connections to transaction or time-shared computers were common¬ 
ly at 10-30 characters per second (cps). The telecommunications networks of 
cluster controllers and multiplexors were sized carefully in terms of terminal, 
cluster fan-in, and leased circuit capacity so that they could handle peak terminal 
loads with acceptable maximum transaction access delay, which meant that there 
was excess capacity in times of less-than-peak loads. 

Between the need for immediate transmission (such as in an airline reserva¬ 
tion system requiring transmission in less than a few seconds) and the need for 
bulk transmission, which could be satisfied by physical movement of magnetic 
tapes or card decks, was the need for transmission within hours, up to perhaps a 
day, of textual information handled by message-switching systems. Application 
computers were connected to each message switch in a network of message 
switches, and these computers sent files (often in the form of virtual punched 
card decks) to other computers on the message-switching network. To optimize 
the use of leased communication circuits, each message switch had a disk drive 
connected to it, onto which the files were spooled until there was circuit capacity 
available to the desired destination computer’s message switch. The delay often 
lasted many hours or overnight. Normally, each of these message-switching sys- 
-lS2B.was specially built by a nonvendor company for a particular application in a 
-Tpi^icular institution, with many application-specific functions provided by the 
"data: communications system. This situation meant that compatibility among 
systems was impossible. 

Thus, the terminal telecommunications networks were typically optimized 
for minimum communication delay (sacrificing circuit utilization), whereas the 
message-switching networks were typically optimized for circuit utilization (sac¬ 
rificing minimum communication delays). 

During this era, computers with l-/rs instruction times were considered quite 
fast, and a computer had relatively little memory (e.g., 4, 8, 16, or 32 kilowords). 
Dial-up communications circuits operated at 100-1200 bits per second (bps) (10 
to 120 characters). Also available at these speeds were leased circuits of 10,000 
and 50,000 bps, requiring special telephone company equipment at subscriber 
sites that were coming into use. 

Scientific computer applications in the mid-1960s were often written in 
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FORTRAN, and business applications were often written in COBOL, but appli¬ 
cations were written in assembly languages almost as often, and virtually all 
systems programming was done in those languages. Assembly languages had 
little or no commonality from machine type to machine type, and even with 
FORTRAN and COBOL, computer vendors competed with each other with 
regard to special versions much more than in adherence to standards. Many other 
high-level languages had been invented, forgotten, or used by various subcul¬ 
tures. For example, the artificial intelligence (AI) community used LISP, the U.S. 
Air Force used Jovial for strategic radar applications, and BCPL, an early fore¬ 
runner of C, was just being invented. 


ARPANET Antecedents 

In the early 1960s, ARPA funded research and development that led to much of 
the early work in the development of time-shared computer systems. Thus the 
concept of sharing computer resources was familiar within ARPA. To encourage 
this concept, ARPA sponsored a study entitled, “A Cooperative Network of 
Time-Sharing Computers” in 1965 (I). This study examined the basic idea of 
computer networking, considered the available communications techniques and 
software issues, and recommended that a three-computer experimental network 
be constructed. As a result of the study, the 0-32 at Systems Development 
Corporation in Santa Monica, California, and th e TX-2 at Massachusetts Insti¬ 
tute of Technology (MIT) Lincoln Laboratory were linked (directly, without 
packet switches), and the link was demonstrated; later, a small Digital Equip¬ 
ment Corporation computer at ARPA was added to form “The Experimental 
Network.” 

ARPANET had two other important antecedents. Many concepts central to 
the later development of ARPANET and other computer networks were first 
described in a series of reports published by Paul Baran and his colleagues at The 
RAND Corporation in 1964. One of these ideas was the improved reliability of a 
distributed network structure over a centralized, or star, network and over so- 
called decentralized networks made up of a collection of smaller star networks. 
Other ideanScluded a “multiplexing station” connecting up to 1024 terminals of 
widely di^Smg characteristics; automatic user-to-user cryptography integrated 
into the-netwbrk'-switching technique to ensure efficiency; use Of both satellite 
links and low-cost microwave relay systems as techniques for providing the net¬ 
work with very high data-rate circuits; and the concept of a “message block” (a 
packet of up to 1024 bits of header and data that is the unit of data transferred in 
the network). One of the most interesting conclusions reached in this study was 
that a large-scale digital transmission network was not only feasible but also 
highly cost effective. The study contained the proposal that many of the switch¬ 
ing functions be implemented in hardware. Baran was considering ways of mak¬ 
ing extremely reliable networks, and thus he preferred simple solutions and 
reliable hardware where possible (2). 

Another early major network development was undertaken at the National 
Physical Laboratory (NPL) in Middlesex, England, under the leadership of D. 
W. Davies. The broad system design of the NPL Data Network, as it was called. 
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was first published in 1967 (3) and bears a resemblance to the network proposed 
by Paul Baran at RAND and to ARPANET. The NPL Data Network was speci¬ 
fied to be a packet-switching network and was to have a hierarchical structure. It 
was proposed that local networks be constructed with interface computers that 
were responsible for both multiplexing among a number of user systems and for 
communicating with a high-level network that could be constructed with switch¬ 
ing nodes connected by megabit-rate circuits. 

Although there was considerable technical interchange between the NPL 
group and those who designed and implemented ARPANET, the NPL Data 
Network effort appears to have had little fundamental impact on the design of 
ARPANET. Such major aspects of the NPL Data Network design as the stan¬ 
dard network interface, the routing algorithm, and the software structure of the 
switching node were largely ignored by the ARPANET designers. There is no 
doubt, however, that in many less fundamental ways the NPL Data Network had 
an effect on the design and evolution of ARPANET (4). 


Activities of the ARPA Community Leading to ARPANET 

ARPANET was sponsored by the Information Processing Techniques Office 
(IPTO) of ARPA. From the time of its first director, J. C. R. Licklid er (1962- 
^1964), IPTO had considered the computer’s role as a communications medium 
between people much more important than its role as an arithmetic engine. 
^Following Licklider at IPTO were Ivan Sutherland, Robert Taylor, and Lawrence 
Roberts (Roberts was special assistant to the Deputy Director of ARPA first and 
then IPTO Director). During the years 1967 and 1968, IPTO energies were spent 
in promoting interest in the network project, both within the government and 
with IPTO contractors, deciding the fundamental structure of the network, writ¬ 
ing a request for quotation, selecting a contractor, and pursuing other related 
activities. 

At an annual meeting of the principal investigators from each of ARPA’s 
university and other contractors i n early 196 7, the group agreed that work should 
begin on the conventions to be used for exchanging messages between any pair of 
_coinputers in the proposed network, as well as on consideration of the kinds of 
^q^munications lines to be used. In particular, they decided that they should 
:es^lish an interhost communication protocol that would include conventions 
for character and block transmission, error checking and retransmission, and 
computer and user identification. The initial idea was to connect all of the 
computers by phone lines so that any computer could establish communication 
with any other computer by dialing it on the telephone. A small interface pro¬ 
gram in each computer would perform a message-switching and transmission 
function, deciding how to reach another computer and transmitting the message 
to it. 

By the end of the meeting, the group concluded that a small interface com¬ 
puter should be inserted between each participant’s computer and the phone line. 
This interface message processor (IMP) was to perform the functions of dial up, 
error checking, retransmission, routing, and verification on behalf of the re¬ 
searchers’ computers (called hosts). Thus, the IMPs plus the telephone lines 
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would constitute a message-switching network. The interface between a host and 
an IMP was to be a digital interface of a simple sort, requiring no host consider¬ 
ation of error checking, retransmission, and routing. 

The major disadvantage of inserting the IMPs was the cost of installation of 
another computer beside each host. The major advantage of inserting them was 
that a unified, straightforward network design could be built and implemented 
without undue consideration of the variations and constraints of the host com¬ 
puters. Other advantages included the following: 


• It was simpler to modify the network of IMPs than to modify all the host 
computers as the network evolved. 

• The IMPs would relieve the hosts of the communications burdens they were 
initially scheduled to carry. 

• If necessary, IMPs could be located at strategic connection points within the 
network to concentrate messages over cross-country phone lines. 

• A network of IMPs was likely to be implemented faster than a network of 
directly connected hosts. 

• The network of IMPs provided a distinct network entity that would be useful 
in presenting the network publicly. 


By the summer of 1967, a draft of the data communications protocols con¬ 
tained the following specifications: full-duplex binary serial transmission at a 
minimum rate of 2400 bps in each direction; automatic answering of incoming 
calls and automatic dialing to originate outgoing calls at each site; ASCII charac¬ 
ters; use of 16-bit cyclic redundancy checksums (CRC); a specific communica¬ 
tions syntax; use of either a text or binary format (the latter using DLE doubling 
for transparency); and certain control conventions. This draft also noted that the 
concept of using IMPs was gaining support. 

A meeting was held in October 1967 to discuss the protocol paper and specifi¬ 
cations for the IMP. The meeting announcement also included a survey to be 
filled out by members of each of the 19 potential network locations, asking them 
to make gross guesses about projected total traffic to other network locations by 
mid-1969r^. well as the percentage of total traffic to each other location. The 
proposgtPh^fwork was to be known as the ARPA Networlc. Topics discussed at 
the OctDtJrf.meeting included message formatting, m essage protocol s, dynamic 
rojil ing and message propaga tion, queuing, error control, measurements, and 
IMP-to-host comm unic ation. 

In a memorL^rence Roberts noted that the discussion at the meeting had 
helped him formulate many plans, and he stated that leased 50-kilobit-per-sec- 
ond (Kbps) communications lines would be used, both because of the vastly 
improved response time that could be obtained with these lines as compared to 
the previously proposed 2.4-Kbps lines and also to eliminate the slow dial-up 
procedure. The nature of the telephone tariffs available to the government made 
use of 50-Kbps lines comparatively inexpensive. Normally, each IMP would be 
connected permanently to three other IMPS via the leased 50-Kbps lines, and the 
IMPs were to use store-and-forward techniques to provide fast message handling. 
Each IMP was to accept messages of up to 8000 bits from its host computer and 



346 


ARPANET, the Defense Data Network, and Internet 


to break these messages into 1000-bit packets. Each packet was to be treated 
independently and routed on one of the three inter-IMP lines. When a packet 
arrived at an IMP, it was to be stored, error checked, and routed on to a further 
IMP. At their destination, packets would be held until an entire message could be 
assembled and then delivered to the destination host. 

With three lines per IMP, approximately three store-and-forward stages 
would be necessary to get a message from any one of 20 locations to any other. A 
! 6-bit CRC would be computed for each message, possibly by a special hardware 
attachment to the IMP. An 8-bit binary format was to be used, requiring the IMP 
program or special hardware to provide packet framing and allow complete data 
transparency. Finally, the connection between the IMP and host was to use a 
single serial line between a shift register in the IMP and a shift register in the 
host, with the shift registers matched to the word sizes of the IMP and host. This 
serial line was to be capable of operating at 8 megabits (Mb). The need for 
control lines between the IMP and host was noted also. 

The first half of 1968 was a time of intense study of the methods to be used in 
ARPANET, leading to a number of significant results. These included the deci¬ 
sion to use a 24-bit CRC to greatly increase the mean time between undetected 
errors, early ideas on host protocols, ideas for network simulation, preliminary 
network queuing analysis, the idea of including a transcontinental link in the 
initial network configuration, and ideas for possible network experiments. 

In parallel with the individual research that was going on, ARPA (with help 
from several members of the research community) moved to pull together an 
IMP specification that could serve as the basis for a work statement for a 
competitive procurement; by June 1968, the ARPANET procurement had started 
officially. The ARPA Program Plan for the ARPANET, entitled “Resource Shar¬ 
ing Computer Networks,” was submitted on June 3, 1968, and approved by the 
Director on June 21, 1968. The fiscal year 1968 ARPA budget included approxi¬ 
mately $500,000 earmarked for the ARPANET effort.* 


The Immediate ARPA Goals 

Tt^tated objectives of the ARPANET program were to develop experience in 
TffeBSOnnecting computers (i.e., communications research) and to improve and 
inc^se'computer research productivity through resource sharing (i.e., avoiding 
duplication of resources). Particularly interesting were the possibilities of re¬ 
source sharing among dissimilar computers and the use of special-purpose com¬ 
puters from general-purpose computers. Technical needs in scientific and mili¬ 
tary environments were cited as justification for the program objectives. 

The computer research centers supported or partially supported by IPTO 
provided a unique testbed for computer networking experiments, as well as 
immediate benefits to the centers and valuable research results to the military. 
The need for a network information center was noted. A five-year schedule for 
network procurement, construction, operation, and transfer out of ARPA was 
planned (it is noteworthy that IPTO initially had eventual transfer of the opera- 


*See Ref. 5 for a personal perspective on the history of packet switching and ARPANET by Roberts, 
which was written almost contemporaneously with this article. 
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tional network to a common carrier in mind), and a several-million-dollar, sever¬ 
al-year budget was planned also. 

The Defense Supply Service-Washington (DSS-W) agreed to be the procure¬ 
ment agent for ARPA. At the end of July 1968 the request for quotation (RFQ) 
for a network of IMPs was mailed to 140 potential bidders who had expressed 
interest in receiving it. In all, 12 large proposals were actually received by DSS-W, 
presenting an awesome evaluation task for IPTO, which at that time normally 
awarded contracts on a sole-source basis. Attempting to evaluate the proposals 
“strictly by the book,” an ARPA-appointed evaluation committee retired to Mon¬ 
terey, California, to carry out their task. 

ARPA was pleasantly surprised that several of the respondents believed that 
they could construct a network that performed as much as five times better than 
the delay constraint given in the RFQ. Four bidders were rated within the zone of 
contention to receive the IMP contract, and supplementary technical briefings 
were requested from each of these bidders. Final negotiations were carried out 
with two finalists, and one was chosen the week before Christmas in 1968. The 
contract was awarded to Bolt Beranek and Newman Inc. (BBN) of Cambridge, 
Massachusetts, and work began the second day of the new year in 1969. 

In parallel with the competition for the IMP contract, ARPA held a competi¬ 
tion among the common carriers to obtain the communications tines for the 
initial network. The contract was awarded to AT&T by the Defense Commercial 
Communications Office in early September 1968. 


Economic Analysis 

In their 1970 paper (6), Roberts and Wessler considered some of the then-current 
economic and technical tradeoffs on which the ARPANET design was based. As 
already mentioned, the overriding economic benefit was thought to be the elimi¬ 
nation of the need for each computer site to replicate software, data, and other 
resources (although this value was not quantified). The most dynamic form of 
this design advantage — one computer calling dynamically on a program or data 
in another computer—has always been possible with ARPANET but is not as 
widely useJESs the almost equally convenient and simpler method of transferring 
a neede<Ep^ram or data file from one computer to another. Both methods save 
multipleTsIfes-from having to generate the same programs or data. 

Also it was implicit that other intangible (or incalculable) efficiencies were to 
be gained by permitting geographically separate researchers to be in faster and 
closer contact with each other. This capability has proved very valuable: the pace 
and efficiency of research has increased visibly as a result of ARPANET. A 
reliable, prompt, and economical intercomputer message service was designed. 
Reliability was achieved by configuring the network to have two communication 
paths from every source to every destination, by providing retransmission of data 
over communication circuits, and by having high mean time between failures 
(MTBF) for the IMPS and lines. Prompt delivery was provided by basing the 
network on high-speed communication circuits, by configuring the network to 
have enough capacity to keep queuing delays low and enough connectivity to 
keep the average source-to-destination path short, and by having only a small 
amount of core memory buffering in the IMPs. The network was made economi- 
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cal by trying to keep the communications costs at less than 25% of the host 
computer costs. This feat was accomplished by configuring the network lines, 
capacities, and connectivity to take advantage of the statistical averages of user 
demands by using simple, cheap, unattended IMPs and by performing network 
maintenance and monitoring centrally. 

At the time, Roberts and Wessler (6) estimated that the cost of sending a Mb 
of data 1400 miles was as follows: 


Telegram $3,300 

Telex, night letter $200-600 

Wide-area telephone service (WATS), 300-2000 bps, dialed 
line $1.50-22.00 

2000 bps-50 Kbps, leased line $.20-.60 

Airmail magnetic tape $.03 


Leased high-speed service was the obvious choice for anything needed in minutes 
or hours, rather than days. 

Roberts and Wessler (6) also analyzed the cost of a 20-node network versus 
network delay for the alternatives of fully interconnected 2.4-Kb and I9-Kb 
leased-line systems; 50-Kb and 2-Kb dial-up service; star networks using I9-Kb 
(not shown because it saturated just below 1 Kb per node pair and thus was not 
competitive with ARPANET) and 50-Kb leased lines; and ARPANET using 50- 
Kb lines. They provided the chart shown in Fig. I, which illustrates cost per Mb 
versus delay, where each rectangle outlines the variation caused by a block-size 
variation of I-IO Kb and capacity variation of 500-1000 bps. Their analysis 
showed some of the potential of ARPANET. 

Finally, ARPANET was expected mainly to send small messages, and it per¬ 
formed very well for these in terms of effective bandwidth versus block size. 


Implementation of ARPANET 

-T^te juirements and Specifications 

-TiTte-Request for Quotation (RFQ) from ARPA specified both administrative and 
technical aspects of the contractor selection and project implementation efforts. 
Because this was a research/development effort, bidders were expected to use a 
cost-based approach rather than to quote a fixed price. ARPA did not want 
technical innovation to be stifled by undue cost pressure on the contractor; it 
wanted a joint decision process. The RFQ specified that responses would be 
evaluated on four criteria in addition to cost: (1) understanding and depth of 
analysis of technical problems involved (30%); (2) availability of qualified, expe¬ 
rienced personnel for assignment to software, hardware, and installation of the 
system (25%); (3) estimated functional performance and choice of hardware 
(25%); and (4) general quality, responsiveness, and corporate commitment to the 
network concept (20%). 

Bidders were asked to provide a system desigrt for a 19-IMP network, but to 
price a 4-IMP network. A 13-month performance period was requested to in- 
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FIG. 1 Cost versus delay for potential 20-node network designs. (Reprinted with permission 
from Ref. 6.) 


elude design, construction of a prototype IMP, and implementation and installa¬ 
tion of four operational IMPs. The four IMPs were to be installed nine months 
after start of the contract, and the contractor was to support them in the field for 
three months after installation. The contractor was required to take full system 
responsibility, although subcontracting a portion of the work was a possibility. 

Altlioggh there was room within the guidelines of the RFQ for the contractor 
to exelS^;^^echnical judgment in many matters, ARPA-in fact knew what it 
wanted;n^d the basic network design should be credited to ARPA and the 
researchers who helped ARPA in 1967 and 1968. The document was an RFQ for 
the implementation of ARPA’s system design, not a request for proposal for an 
alternative system design. 

The IMP specification clearly delineated the division of responsibilities 
among host sites, the telephone company, and the IMP contractor. Each host site 
was responsible for designing and implementing the hardware and software nec¬ 
essary to attach the host to the network and the hardware and software to utilize 
other hosts on the network. The telephone company was responsible for provid¬ 
ing necessary circuits, data sets, and line-conditioning equipment used by the 
network. The IMP contractor was responsible for providing necessary hardware 
and software to connect IMPs to each other using the circuits supplied by the 
telephone company and to connect IMPs to hosts, as well as for providing 
hardware and software necessary to implement the procedures that allowed crea- 
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tion of a network of IMPs capable of forwarding messages from one host to 
another. 

ARPA’s functional description of an IMP included; 


• use of messages not longer than 8192 bits, which would be broken into 
packets of not more than 1024 bits 

• IMP provision of message- and packet-buffer space to permit speed conver¬ 
sions to take place, provide queuing space in the face of delays, and pcnnil 
retransmission in the event of erroneous transmission 

• a routing algorithm that would take into account the connectivity of the 
network, IMP and line utilization, and message priority, and use this infor¬ 
mation to forward a packet to the next IMP on a path to the ultimate 
destination, and to include periodic updates based on exchange of routing 
and loading information with other IMPs and hosts 

Other requirements were as follows: 

• IMPs would take messages from a local host at the IMP’S convenience, but 
send messages to a local host at the host’s convenience. 

• IMPs would be able, when commanded, to measure selected network param¬ 
eters and trace the movements of selected messages through the network. It 
would be possible to transmit the data resulting from these measurements and 
tracings to a host, and the measurement activity would be capable of initia¬ 
tion and termination by a host or another IMP. 

• IMPs would detect and recover from various IMP, host, and line failures, and 
it would be possible to stop, start, examine, or reload IMPs from selected 
network hosts. 

• Because it was thought that host-site programmers could provide special 
host-specific code at each IMP site, it was considered desirable to protect the 
rest of the IMP memory from the portion that the host personnel could 
access and program. 

standard host interface would be specified rather than, a different one for 

.rfr^each host. 

^^^~^ach'bidder would consider the cost of providing interfaces to multiple hosts 
per IMP, although only one host interface was required. 

• Sufficient program space would be left to do host-specific character-code 
conversion and repacking of binary messages. 

• The interface between an IMP and its telephone lines would be required to 
have hardware to sense characters, detect control characters, calculate and 
check the 24-bit CRC, provide a real-time clock with lO-fis resolution, and 
provide fault and status information. 

• The IMP would be optimized to handle three lines but would be capable of 
handling six. 

• The average message delay for a short message to go from a source IMP to a 
destination IMP would be less than Vi second for a fully loaded network. 

• The probability of lost messages and message errors would be very low. 

• Network capacity would not be considered of first importance and would be 
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defined as the maximum bit rate that could be input at every node to still 
maintain the message delay at less than V 2 second —a 20-kb network capacity 
was hoped for. 

• Host-to-host traffic flows were estimated, yielding the hypothesis that there 
would be a trimodal distribution of traffic type (high rate/short length, medi¬ 
um rate/medium length, and low rate/long length). 

• The bidder was asked also to consider the provision of memory protection to 
facilitate simultaneous IMP operation and testing of new software, and to 
consider what additional hardware and software would be necessary for an 
IMP to provide a terminal concentration capability for its host or for the 
network (i.e., no host, just terminals). 


Initial Implementation 

The initial four-node ARPANET configuration connected an IMP and its host at 
each of the following four locations: University of California at Los Angeles 
(UCLA); Stanford Research Institute (SRI) in Menlo Park, California; Universi¬ 
ty of California at Santa Barbara (UCSB); and the University of Utah in Salt 
Lake City (7). The UCLA, UCSB, and SRI sites were connected in a triangle; the 
University of Utah was connected to SRI (see Fig. 2). Leased circuits operating at 
50 kbps were used between IMPs. The initial four-node configuration was in 
place by the end of 1969. The network was quickly expanded. By mid-1970 it 
included nine sites —the RAND Corporation and System Development Corpora¬ 
tion (SDC) were added in Santa Monica, California; MIT, Harvard University, 
and BBN were added in the Boston area; and there were two cross-country 
connections —Utah to MIT and BBN to RAND (see Fig. 3). 

The computer hardware selections were motivated largely by a defensive de¬ 
sign strategy that was conservative enough that the hardware was unlikely to 
cause problems. The computer hardware for the IMP, the Honeywell DDP-516, 
was chosen from the economical computers that were then available with fast 
cycle times (e.g., 1 fis) and good instruction sets. The 516 could handle the 
anticipated maximum traffic levels readily, had been proven through field use, 
and waS!2?ailable in a ruggedized configuration (considered valuable for unat- 
tendedrop^ation at host sites). Also, Honeywell’s DDP Division was located 
convenieMy-near BBN. The 516 had a 16-bit word length and a .96-^s cycle 
time; it was configured with 12 kilowords of memory, 16 multiplexed data input/ 
output (I/O) channels, a 16-level priority interrupt system, a lOO-fiS clock, and a 
set of programmable status lights. A Teletype and paper-tape reader were includ¬ 
ed for maintenance and software loading. 

BBN designed special interface boards, constructed by Honeywell, to connect 
to the 50-kbps inter-IMP phone lines and to connect IMPs to hosts. The IMP/ 
line interface included logic to send and receive packets of data, append and 
check the 24-bit CRC, provide transparent transmission of binary data (i.e., 
DLE-doubling and -undoubling), and mark and detect packet beginning and 
end. The IMP/host interface included logic to send and receive data messages, 
using a full-duplex bit serial transmission of data controlled by a few control 
signals (beginning of message, end of message, next bit, bit acknowledgment, 
etc.) (8). 
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The bit serial transmission was simple, and it dealt with the problem of 
different host and IMP word sizes (not necessarily multiples of eight bits in those 
days). The IMP/host and IMP/line interfaces were designed to operate at easily 
attainable speeds (nowhere near the 20 Mbps suggested for the host interface in 
the RFQ specification), in ways that did not put undue pressure on the interrupt¬ 
handling requirements of the software. To enable diagnosis of line, IMP, and 
host problems, the IMP/host and IMP/line interfaces contained control signals 
to loop the output back to their inputs and to enable each IMP/line interface to 
loop the phone line back on itself. 

Although the specification called for handling one host and several inter-IMP 
lines per IMP, when the IMP development was barely underway it became appar¬ 
ent that many sites would have more than one host. Thus, the IMP hardware and 
software were designed to support various combinations of hosts and inter-IMP 
lines, allowing a combined maximum of seven. It became evident that at many 
sites with multiple hosts, the IMP provided the first practical method of inter¬ 
connecting them. Based on certain ideas in the RFQ, the message format speci¬ 
fied by the IMP developers included a simple host-addressing convention, with 
addresses for four hosts on an IMP and 64 IMPs in the network (8). 

The IMP software was a fairly conventional, real-time interrupt-driven pro¬ 
gram. It was written in an assembly language with the capability of defining 
macro instructions. Real-time interrupt-handling capacities were calculated 
based on maximum line speed and message- and packet processing requirements, 
and the program’s interrupt routines were designed and implemented to handle 
these speeds safely. 

The software was implemented as a set of interrupt-driven modules com¬ 
municating through packet queues and data tables. Figure 4 illustrates the inter¬ 
nal organization of the software from the viewpoint of packet flow. The two 
modules shown at the right of the figure (modem-to-IMP and IMP-to-modem) 
handle packet I/O for the inter-IMP circuits. Two similar modules shown at the 
left (IMP-to-host and host-to-IMP) handle message I/O for the hosts. The Task 
module, shown in the center of the figure, handles the routing of store-and- 
forward packets, the retransmission of unacknowledged packets, and the reas¬ 
sembly of packets into messages at the destination. 

In additron to the modules directly involved with packet flow, there are mod¬ 
ules thaT")5RJvi.de periodic updates of routing tables based on routing-informa¬ 
tion packets-rreceived from neighboring IMPs and queuing of routing-informa¬ 
tion packets for neighboring IMPs. Other modules handle periodic garbage 
collection of packet queues and other data structures and timing out and recover¬ 
ing from uncompleted events. Finally, the Background module, shown at the left 
center of Fig. 4, is responsible for construction, transmission, and receipt of 
statistics, trace and artificial network loading messages, debugging, and other 
IMP control and monitoring messages. 


Expansion Phases 

The subnetwork of IMPs and telephone circuits provided a system for tran.s- 
parently moving messages of up to about 8000 bits between hosts at the same or 
different sites. The plans for the IMPs to provide character-set conversion and 
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FIG. 4 IMP internal packet flow. (Reprinted by permission from Ref. 7.) 


permit host-specific code (e.g., for word-size matching) to be installed in the 
IMP were not implemented. To communicate with each other, hosts with differ¬ 
ent operating systems, word sizes, file systems, character sets, and terminal¬ 
handling conversions had to agree on a common set of communication conven¬ 
tions that came to be called communication protocols. 

Representatives from potential host sites undertook development of the host- 
to-host communication protocols. This group, called the Network Working 
(NWG), had a membership that changed over tirne. ARPA provided 
.Toreeasional guidance, assigned certain people to leadership positions, and set 
-rleadliiies. Documenting (and often conducting) its deliberations through Re¬ 
quests for Comments (RFCs), the NWG struggled to accommodate everyone’s 
theoretical ideas and practical implementation constraints. The group tried to 
balance a desire for a set of protocols that would support very sophisticated 
distributed computation and adapt to changing needs with a need to get some¬ 
thing implemented quickly. They were also dealing with the problem that they 
did not really know how the network would work. Although there were a number 
of early ad-hoc communications protocols, such as those between similar hosts 
or pairs of sites with a great urge to communicate, it was not until a meeting at 
MIT of representatives of all host sites in October 1971 that there was general 
agreement on the first version of host protocols and widespread implementation 
began. 

The NWG adopted a layered approach to host protocols. Following this 
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approach, the higher level protocols use the services of the tower level protocols. 
The lowest host layer was the IMP-to-host protocol, which specified the electrical 
interface, link control, and message format for communication between an IMP 
and a host. The next layer (called the host/host layer) specified methods for 
establishing communication paths between hosts, managing buffer space at each 
end of a communication path, and similar tasks. Next, the initial connection 
protocol, or ICP, specified a standard way for a remote user or process to attract 
the attention of a network host, preparatory to using that host. The ICP provid¬ 
ed a function analogous to that of the user pressing the attention button at a 
terminal connected directly to a host. 

The next layer was the Telecommunications Network (Telenet) protocol (9), 
which was designed to support terminal access to remote hosts. Telnet is both a 
specification for a network standard terminal and a protocol for communication 
between such a standard terminal and a host. The next logical protocol layer 
contained such function-oriented protocols as the file transfer protocol (FTP) 
and the remote job-entry protocol (RJE). Other function-oriented protocols 
defined for ARPANET included an electronic mail protocol and a digital speech 
protocol. Finally, at any point in the layering process, it was possible to superim¬ 
pose ad-hoc protocols. 

The first specific protocol design undertaken by the NWG was the develop¬ 
ment of the host-to-host protocol, called the Network Control Protocol (NCP). 
The NCP was intended to address the level of error control required, multiplex¬ 
ing (over the IMP/host interface), flow control (so host input buffers would not 
be overflowed), out-of-band signaling (to break out of deadlocks), and resyn¬ 
chronization after failure or restart of a host-to-host transmission. A virtual 
circuit, called a connection, was set up at the beginning of a session or transac¬ 
tion and taken down at the end. Flow control was exercised for each connection. 
A global networkwide name space was defined for identifying the ends of a 
connection (each end was identified by a 32-bit “socket” number). Some of these 
sockets were permanent —for example, socket 1 on each host was always the 
address called by the ICP—and some were dynamically allocated —for example, 
to identify a particular I/O port in a particular instance of a particular process. 

Unfortunately, although the IMP design generally tried to isolate the IMP 
from kn ow ledge of host-level function, the NCP designers, led on by early ideas 
of the fiMl^esigners, assumed too much dependence on the IMP-to-host proto¬ 
col. Thet^iCP.'assumed totally reliable transmission of messages and in-order 
delivery of messages over the IMP subnetwork; it depended on an IMP-provided 
destination-IMP-to-source-IMP acknowledgment as a host-to-host acknowledg¬ 
ment, and it used some of the identification bits (called the link) in the IMP- 
specified message header as an abbreviation for a full 64-bit socket/socket pair. It 
also assumed that the subnetwork could transmit 8000-bit messages in 1000-bit 
packets. 

Greater understanding of the problems of flow and congestion control in the 
IMP subnetwork gave the lie to the assumptions of infrequent message loss in the 
subnet. It became clear that effective congestion control required that there be no 
more than one message at a time over a link, and thus over a host connection. 
This limitation greatly reduced the bandwidth of each host connection (although 
not the total traffic possible between a pair of hosts over multiple connections) 
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and left the hosts with inadequate means for detection and recovery from lost 
messages because they had assumed a perfect subnetwork and implemented 
nothing at the host level. These problems, along with the use of the too-simple 
IMP-based message identification and the incorrect assumptions about subnet 
message size and in-order delivery, made the NCP unsuitable for reliable, high 
performance on ARPANET and impossible to use in a multinetwork situation. 
Nonetheless, hosts operated around these problems, and ARPANET was used 
extensively from the time NCP implementations first became widely available. 

Early in ARPANET history, it became clear that users at sites without host 
computers should be able to access “service hosts” on the network; this was 
completely in keeping with the idea of using ARPANET to reduce the need to 
replicate computer resources at every site. Consequently, the IMP contractor 
began to build a hardware device to handle terminals of various speeds and types 
that were attached to a minicomputer in which the NCP and Telnet protocols 
would be implemented. Called a Terminal Interface Processor (TIP), this com¬ 
puter sat near an IMP and handled 64 local and dial-up terminals. On behalf of 
these terminals, the TIP made connections to user-specified hosts and did the 
necessary protocol conversions and procedures to permit a terminal to use a host 
thousands of miles away much as if it were a local terminal to the host. 

The availability of the TIP and protocol implementation marked the first 
major milestone in computer resource sharing on ARPANET. It also resulted in 
the first major complaints about network operation, as users appeared who were 
interested in simply using the network for their own research. From these users’ 
points of view, the network did not work if they could not access their host 
program. They did not care whether a problem was the responsibility of the 
phone company providing the dial-up terminal line, the TIP and IMP main¬ 
tained or the host computer. These complaints resulted in a major effort to 
improve and coordinate available fault-diagnosis capabilities and to provide clear 
guidance to users about what to do in case of faults. At the suggestion of Robert 
Kahn, who was in the process of moving from BBN to ARPA, the TIP was 
demonstrated in Washington, D.C., at the First International Conference on 
Computer Communications in October 1972. This demonstration significantly 
enhanced ARPANET’S credibility, as the TIP and all the hosts had to be de- 
birg^d thoroughly for this major public demonstration., 

T^^a^ker early ARPANET experiments in. resource sharing included connecting 
tlie^|Iliac IV (an early ARPA parallel processing project), the Datacomputer (a 
very large disk file system), MULTICS, a large 360/91 service host, and, ulti¬ 
mately, 14 Tenex hosts to the network. The Illiac IV never worked well enough in 
its own right to be an important network resource. The Datacomputer was used 
in a number of experiments that added significantly to the state of the art of very 
large and distributed database systems. MULTICS, a major virtual-memory 
time-sharing system development project at MIT (10), was given substantial over- 
the-network use. The 360/91 was used operationally by many users seeking num¬ 
ber-crunching computer cycles. Tenex, an early DEC-lO-based, virtual-memory 
time-sharing system, became a subculture in the ARPA community, used by local 
and remote users (as UNIX hosts are used today) as the basis of many ARPA 
research programs and as the electronic-mail hosts that DARPA and its contrac¬ 
tors accessed most often for coordinating and managing ARPA projects. 
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Perhaps the biggest surprise of early ARPANET use was the enthusiastic 
(even zealous) adoption of electronic mail as the primary medium for scientific 
and management communication in the DARPA research community, both in¬ 
tersite and intrasite. In an early host protocol design meeting, Roberts had in¬ 
structed the designers to make the protocol work for electronic mail. Electronic 
mail provided the first major boost to research productivity through ARPANET 
computer resource sharing, that is, it allowed researchers quick sharing of their 
most important resource, the results of their intellectual creativity. 

Figure 5 shows the growth of host internode traffic (i.e., not including the 
substantial traffic among hosts on the same IMP) for the first few years of the 
ARPANET. The traffic grew by about another order of magnitude since that 
time; an average of 77,448,692 packets per day were measured during a typical 
week in June 1988. 


Network Evolution and Operations 

ARPANET planners and designers understood early on that the IMP sub¬ 
network itself (high-speed lines, redundant paths) provided a superb medium for 
monitoring, controlling, and diagnosing the IMP subnetwork. Each IMP sent 
performance and line-error statistics to a central location (a small minicomputer 
connected to a particular network IMP) once a minute, and immediately in the 
case of full failures (e.g., a neighboring IMP disappears, a host interface goes 
down, a line goes down). Thus, with a few exceptions, the IMP ARPANET did 
not use an out-of-band “tech control” network to monitor and diagnose 
ARPANET network components, and sites were not manned. Both of these 
characteristics broke with the tradition established by message-switching net¬ 
works. It was also possible for network operators at the central site to perform 
remote inspections of (and, if necessary, change) IMP memory to diagnose and 
fix the more unusual network problems. 


Software and Hardware Upgrades 

As the flsearork matured, corrections of software bugs and new features were 
distributcch'a^a .the network (every Tuesday from 7 to 9 a.m. eastern time was 
reserved for network software updates). Of course, as the network evolved, some 
of these new releases took months to code and test completely. In some cases, 
they resulted in significant changes in network function. These changes were 
coordinated closely with host sites. They were constructed to be backward-com¬ 
patible for a period that would allow hosts to make matching changes, and to be 
reversible (no easy trick) in the event of an unanticipated difficulty in getting a 
release distributed and working. See Ref. 11 for a discussion of this fascinating 
and very necessary craft. 

The network data collected at the central site (the network operations center) 
was used for planning such network changes as upgrading or adding phone lines 
in busy regions, and helping to detect and diagnose systemic (but possibly very 
rare) hardware and software problems. For instance, in one case where a problem 
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FIG. 5 Growth in average host internode traffic. 


resulted from a slow IMP clock, it was possible to process the collected data and 
find other IMP clocks that were going bad before they failed enough to actually 
cause problems. 

The network designers also knew from the beginning that the dynamic rout¬ 
ing algorithm (which chose the best available path through the network) and the 
detection code for dead lines, dead hosts, and dead IMPs and live lines, live 
hosts, and live IMPs provided a method of changing the network configuration 
(changing lines, hosts, and IMPs) without the explicit configuration updates 
reared in earlier networks. 

^^^nfortunately, not all network problems were transieii't errors or planned 
-u^^ades. There is a rather impressive list of design flaws or inadequacies that 
made life difficult for hosts or caused major network outages. We have men¬ 
tioned already the early need to change the IMP/host interface to deal with 
subnetwork congestion control that resulted in long-term performance limita¬ 
tions for hosts because of the too-close dependence of the NCP on the IMP/host 
protocol. 

Soon it also became clear that the completely reasonable decision to permit 
up to four hosts on an IMP was inconsistent with the initial specification of an 
IMP/host bit-serial electrical handshake interface, which worked only up to a 
distance of 30 ft (the so-called local host). Thus, designers developed an option 
for the IMP that hosts could match; it permitted a bit-serial electrical handshake 
up to 2000 ft (the distant host). Next it became clear that two hosts in the same 
town or geographic region should be able to share the same IMP, for economic 
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reasons, even if they were not within 2000 ft of an IMP. This led to the develop¬ 
ment of a software interface that used one of the IMF’s phone line interfaces for 
communication with a host; in other words, the IMP/“very-distant-host” (VDH) 
interface supported packet communication with error detection and retransmis¬ 
sion to a host, permitting 8000-bit messages to be broken into packets at the host 
and received by the IMP as packets in a logical message rather than in a physical 
message. 

Next it became clear that the IMP subnetwork’s efforts to deliver packets in 
the order sent, albeit a good idea in general, was not the best approach in such 
specific instances as real-time transmission of speech or telemetry data. In these 
cases, delays in the delivery of subsequent packets experienced while waiting for 
an earlier packet to arrive caused a bigger problem for the receiving host than did 
the need to sort packets itself or even the loss of an occasional late packet 
entirely. Thus, the IMP/host interface was augmented to permit transmission of 
packets where the hosts were responsible for message and packet ordering. 

Another change in the IMP/host interface was required when the number of 
nodes in the network passed 64. At that time the header fields for the number of 
nodes and hosts per node were increased to 16 bits and 8 bits, respectively. 
Changes also occurred over time to the IMP-to-IMP and source-IMP-to-destina- 
tion-IMP logic in the IMP, but these were largely invisible to the hosts. In 
particular, changes were required to handle a variety of terrestrial and satellite 
circuits of various speeds. 

As the Honeywell DDP-516 computer became old, a decision was made to 
use the Honeywell 316, which was mostly compatible with the 516. The IMP 
software was modified to run on either of these machines so that they could be 
used interchangeably in the network. Next, the Pluribus (12) parallel processor, a 
completely incompatible computer, was built and programmed to be software 
compatible. For a long time all three kinds of IMP hardware coexisted in 
ARPANET. 

Next, the C/30 computer was specially built to be somewhat 316-compatible 
but significantly enhanced, and gradually these machines replaced the 5I6s, 
3I6s, and Pluribuses. Eventually C30s, C/3s (small C/30s) and C/300s (large C/ 
30s) all coexisted in ARPANET. The important lesson here is that it was possible 
to separ^:^jie problems of hardware compatibility from the proble.ms of soft¬ 
ware compatibility. The hardware gradually changed over the years to improve 
performance,but the software worked compatibly over all the computer types 
then present in the network. The software also gradually changed to fix bugs, 
increase function, and adapt to host needs. Each software release worked with 
the previous release for a long enough period to enable users and hosts to adapt 
before the vestiges of the prior release were discarded. 

Practically speaking, ARPANET worked exceptionally well throughout its 
life. It operated virtually nonstop, providing a level of service to hosts and users 
that was adequate, if not always ideal, especially since the hosts cooperated in 
avoiding some of the problems that could have resulted from some of the early 
misconceptions built into the IMP subnetwork. Theoretically speaking, however, 
the existence of problems was always known. Some of these were corrected in 
time (or have been reimplemented several times in such cases as the dynamic 
routing mechanism). Others have been potential problems but have never caused 
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any real difficulty. In a few cases there have been major outages of large numbers 
of network machines for a few hours. Although, on balance, the network has 
worked well, from the point of view of the theoreticians and researchers doing 
their best to invent and implement algorithms that would not fail, the 
ARPANET design and implementation problem has only grown more complex 
over time. As Kleinrock said (13), “Fortunately we were unaware of the enormity 
of the problems facing us, and so we plunged ahead enthusiastically and with 
naive optimism.” 


Problems with Network Design 

At the risk of oversimplifying, one can divide major problems with network 
design into the following categories: inadequacy of the congestion-control algo¬ 
rithms, inadequacy of the dynamic routing, errors in control bits, and miscoding 
of control software. 

Congestion-control problems usually led to lockups. For example, the space 
being held in a destination IMP to reassemble a message could not be freed up 
because some of the packets of the message were unable to get through conges¬ 
tion in the IMPs that were neighbors of the destination IMP. The packets (of 
other messages) causing congestion in the neighboring IMPs could not move on 
to the destination IMP because there was no space available to reassemble a 
message from its packets. Sometimes these lockups were direct, as in the example 
just given; sometimes they were indirect, as when there were sufficient reassembly 
buffers in the destination IMP but insufficient buffers to hold the control block 
used to manage the reassembly buffer space. Congestion-control problems re¬ 
sulted from an inadequacy in the network’s buffer-allocation algorithms or from 
inadequate means (e.g., time-outs) to keep some traffic flowing to dissipate 
temporary lockups before they became permanent deadlocks. Most of these 
inadequacies have been corrected over time, although some of the corrective 
means resulted in less than ideal network performance. 

Dynamic routing has been studied at great length in ARPANET, and the 
network routing algorithm has been revised substantially or totally several times 
.Ter^oid actual or potential problems in packet routing,. A typical routing prob- 
involved packets looping repeatedly within the subnetwork without being 
-de&ered to a destination, typically caused by oscillations in the routing calcula¬ 
tion—as when successive updates of the routing calculation reverse the recom¬ 
mended path on a particular line to a particular destination. Another problem 
involved packets being routed to dead ends in the network topology. For exam¬ 
ple, because of timing problems in the routing calculation, for a period of time, a 
packet destined from Washington, D.C., to Boston, Massachusetts, through a 
network of congested IMPs and lines on the east coast of the United States might 
be sent out on the line from New York City to London, because London briefly 
looked like a shorter path to Boston. Once again, these problems could be 
indirect. Although ARPANET eventually had an adequate routing algorithm, 
there are certain things it was supposed to do that it has never done well, such as 
finding a maximum throughput set of paths between a source and destination 
rather than finding the minimum delay path. 
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Even when the routing algorithm or congestion-control algorithms have been 
working as planned, serious problems have resulted on occasion from the hard¬ 
ware errors affecting the control calculations or data. In fact, the few major 
network lockups have tended to result from hardware errors. For instance, in one 
case the routing calculation was being done correctly, but as one IMP sent its 
routing-update packets to its neighbors for forwarding throughout the network, 
a hardware error caused a bit to be dropped in each packet as it was taken from 
memory and transmitted onto the inter-IMP line. Unfortunately, the incorrect 
bit had the effect of changing the routing packet to say that this IMP was the best 
path to all other IMPs. Thus, all traffic in the network was forwarded to that 
IMP, causing massive congestion. 

The main solution to such bit errors was to checksum the bits resulting from 
control calculation such that bit errors got caught. However, it is hard to check¬ 
sum all control bits in a way that does not take too much calculation and that 
totally eliminates the possibility of undetected bit errors —that is, somewhere 
there may be an uncovered seam between calculations or between memory and an 
I/O channel. 

Errors in coding control were another problem. However carefully one de¬ 
signs, codes, and performs quality control, errors can still slip through. Fortu¬ 
nately, with a large number of IMPs in the network, most of these errors are 
found quickly because they occur so frequently. For instance, a bug in an IMP 
code that occurs once a day in one IMP, occurs every 15 min in a 100-IMP 
network. Unfortunately, some bugs still will remain. If a symptom of a bug is 
detected somewhere in a 100-IMP network once a week (often enough to be a 
problem), then it will happen only once every 2 years in a single IMP in a 
development lab for a programmer trying to find the source of the symptom. 
Thus, achieving a totally bug-free network is very difficult. 


Transition to an Internet 

Internet Concepts and TCP/IP Protocols 

The FirlsmSiternational Conference on Computer Communications was held in 
Washn^o^, D.C., in October 1972. This conference, which included a public 
demonlffat^n'of ARPANET, brought together researchers from most of the 
world’s computer network projects for the first time. Many of these individuals, 
representing projects in Canada, France, Japan, Norway, Sweden, the United 
Kingdom, and the United States, agreed that it was important to begin thinking 
about the protocols that would be needed if their networks were to be intercon¬ 
nected. To provide a forum for this activity, they formed the InterNetwork Work¬ 
ing Group (INWG) and selected Vinton Cerf, an assistant professor at Stanford 
University and member of the ARPANET NWG, as its first chairman. Soon 
afterward, INWG became a working group of the International Federation for 
Information Processing (IFIP). 

The INWG members immediately began a vigorous exchange of proposals 
for architectural principles to guide the interconnection of networks, and for the 
host protocols that would support use of this concatenated network system, or 
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catenet, by applications. INWG’s vision of the catenet was a mesh of indepen¬ 
dent, autonomous networks interconnected by gateways, just as the independent 
circuits of ARPANET are interconnected by IMPs. 

Gateways would handle datagrams, each of which would contain the address 
of its destination. The host originating the datagram would include in its proto¬ 
col header a “sequence number” of the message; if a gateway had to forward a 
datagram from a network of large message size into a network of smaller mes¬ 
sage size it would fragment the datagram into two or more smaller datagrams. It 
would reproduce portions of the original protocol header (e.g., destination and 
source addresses) in each resulting datagram, and it would compute the appro¬ 
priate sequence number for each. Then the destination host could use the se¬ 
quence numbers to reconstruct the original message. Gateways and the networks 
that interconnected them were not required to perform any other functions; in 
particular, they would not be required to maintain sequence or protect against 
data loss. The source and destination hosts would take complete responsibility 
for these functions. 

In 1974, Robert Kahn, then at AREA, and Vinton Cerf published “A Proto¬ 
col for Packet Network Interconnection” (14), which brought these concepts into 
the open literature and specified in detail the design of the Transmission Control 
Protocol (TCP) that embodied these principles. TCP was a byte-stream protocol; 
sequence numbers were assigned at the byte level and a gateway could fragment a 
datagram at any byte boundary. 

Although the TCP proposal was clearly in the mainstream of the INWG 
ideas, many of its features were viewed by INWG as being unnecessarily costly of 
network bandwidth or host processing power, and, therefore, TCP was' viewed as 
just one more proposal. In the United States, however, researchers representing 
primarily ARPA-sponsored sites formed the Internet Engineering Group, which 
refined and extended the ideas of the original paper into two protocols; TCP, 
which dealt only with issues of interest to the source and destination hosts; and 
Internet protocol (IP), which dealt with addressing and fragmentation issues of 
concern to both the hosts and the gateways. The term internet was used with the 
same meaning as the INWG term catenet. Experimental implementations were 
begun almost immediately. 

. *~fa: 1976. INWG members representing the research networks of Britain, 
and the United States published a joint “Proposal for an International 
EntEto End Protocol” (15), which, if adopted, might have promoted immediate 
worldwide research network interconnection. Unfortunately, implementation of 
TCP/IP in the United States was felt to be too far advanced to switch to an 
alternative system, so European and U.S. efforts diverged. 

By 1981, experience with TCP/IP implementations was sufficient for the 
ARPANET NWG to establish an official transition from NCP to TCP/IP. In 
November 1981, it was announced that cutover would be mandatory by January 
1, 1983. During the 14-month transition period, several relay systems would 
provide translation between NCP and TCP/IP for Telnet (terminal service), FTP 
(file transfer), and electronic-mail services. A series of surveys taken between 
December 1982 and February 1983 showed that of the approximately 285 gener¬ 
al-purpose hosts connected to ARPANET (of a total of about 320 hosts), about 
one-third accepted TCP connections in early December, about one-half in early 
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January, and about two-thirds at the end of February. Although the transition 
had not been completed on quite the original schedule, TCP/IP was firmly 
established by early 1983 and Internet was in place. 


Other ARPA Networks 

ARPA sponsored the development of several other types of networks in the years 
following the initial deployment of ARPANET. The first of these, packet radio, 
existed in the ALOHA system (16) at the University of Hawaii by 1970. A more 
mobile and dynamic version was described in a 1972 paper by Larry Roberts (of 
ARPA) entitled “Extension of Packet Communication Technology to a Hand 
Held Personal Terminal” (17). The system described in this paper was to be based 
on a high-powered central station communicating with small personal radios. 
The packet radio networks actually built by ARPA (18), however, were more 
oriented toward the survivability and rapid deployment needs of the Army, which 
contributed to the support of the research. 

In an Army tactical situation, radios (with terminals and, more recently, 
microprocessors) are envisioned moving with Jeeps, trucks, armored vehicles, 
and perhaps light aircraft. Natural terrain, battle damage, and enemy jamming 
might prevent any given pair of radios from direct communication. One focus of 
the packet-radio research, therefore, was the automatic self-organization of the 
system into a hierarchical store-and-forward system, with individual radios serv¬ 
ing not only as traffic sources and destinations, but also as repeaters for transit 
traffic. The key networking problem is to insure that a packet is “repeated” by a 
site closer to the destination whenever the destination is out of range, but to 
“repeat” as few packets as possible so as not to waste radio channel bandwith. A 
second line of research in the packet-radio program was the development of 
direct-sequence spread-spectrum radio equipment. The signal frequency changes 
at least an order of magnitude more rapidly than does the bit rate, thereby 
spreading the signal for each bit across the radio frequency spectrum so that 
jamming and interception are extremely difficult. 

The packet-radio program has produced two generations of radios and several 
generatiwng^f network protocols. No packet-radio network has been.in continu¬ 
ous daily%ggi but many packet-radio networks have been used in demonstrations 
and in Arrriy exercises since 1979. 

A second type of ARPA-sponsored network development is shared-channel 
satellite networking. Satellites can provide communications services to a wide 
geographic area, including remote locations, and airborne and seaborne users. 
In addition, they can be deployed rapidly. Conventionally, satellites are used as a 
“wire in the sky” —a dedicated point-to-point link between two end points; how¬ 
ever, satellite channel capacity is a relatively scarce resource, and this method of 
use is quite inefficient. Point-to-point satellite link technology allocates the entire 
bandwidth of a satellite channel to what appears to end-user applications as a 
long-delay, full-duplex circuit. The applications that use such circuits efficiently 
are those that generate continuous data rather than carrying out “transactions” 
or request/respqpse sequences. Real-time data collection, real-time digitized 
voice, and similar real-time or fixed-duty-cycle applications can fill the commu- 
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nications links with user traffic continuously. The “bursty” character of most 
computer-to-computer communications applications prevents efficient use of 
point-to-point links. Depending on the specific characteristics of the application, 
the unused bandwidth can be significantly more than 50% of the total bandwidth 
of a point-to-point circuit. 

ARPA’s packet satellite network technology exploits the multiple-access and 
broadcast characteristics of standard satellite channels. Numerous transmitting 
and receiving earth terminals access the same half-duplex channel. A demand- 
assigned TDMA (time division multiple access) protocol, implemented in spe¬ 
cial-purpose satellite packet switches, allocates the shared-channel bandwidth to 
different earth terminals on an instantaneous packet-by-packet basis in accord¬ 
ance with the real-time requirements of the network users. Every packet trans¬ 
mission on the common channel is received by every network terminal in the 
satellite footprint. 

ARPA has sponsored the development of two satellite networks de¬ 
signed according to these principles. The first is the Atlantic Satellite Network 
(SATNET) (19), which was used to interconnect research institutions in the 
United States, the United Kingdom, Norway, Italy, and Germany from 1975 to 
1989. Initially this system used a single 64-Kbps channel and later, when network 
use increased, two parallel but independently scheduled 64-Kbps channels. The 
second is the ARPA Wideband Net (20), which provided service to 10 continental 
US. sites from 1980 to 1989 using a 3-Mbps channel. In particular, the Wide¬ 
band Net provided support for ARPA experiments in multisite video conferenc¬ 
ing and distributed simulation, each of which required more raw bandwidth than 
the ARPANET could provide. 

Each of these types of networks has been interconnected with the ARPANET 
via IP gateways to form part of the Internet. 


Gateways 

In the ARPANET/Internet community, the term gateway refers to a device that 
interconnects networks and routes datagrams according to the Internet protocol 
this is also how the term is used in this article. However, it should be noted 
Tfi^'in other communities the term gateway is used for a device that translates 
^beiSweri two similar but different sets of protocol at any level. A device that 
interconnects networks at the protocol level of IP is often called a router, because 
it chooses a route for each packet. 

As ARPA constructed new packet networks for interconnections with 
ARPANET, and as the specification and implementations of IP solidified, 
ARPA also began to sponsor some gateway development. The first IP gateways 
were implemented on the DEC LSI-11 computer. The demands on these gateways 
were not great; there were only a few networks connected to the periphery of 
ARPANET, all operating at speeds of about 50 Kbps or less. Each gateway could 
have knowledge of all other gateways, all gateways were identical, and all were 
run by a single, central administration. However, as the Internet concept took 
hold, Internet topology quickly assumed the structure of a tree rather than a 
simple star. The root of the Internet tree was ARPANET (this remained true until 
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the mid-1980s), but the branches extended through many levels. The organiza¬ 
tions not connected to ARPANET directly wanted to build and operate their own 
gateways. Many gateways were built as student projects and were viewed as 
neither reliable nor “trustworthy”; yet all the gateways needed to work together 
to perform routing. 

This environment gave rise to the concept of core gateways and exterior 
gateways. Core gateways generally were those connected directly to ARPANET 
or the AREA satellite networks. The core gateways exchanged topology (routing) 
information with each other by means of the interior gateway protocol (IGP), 
and each believed the information received from other core gateways. Exterior 
gateways exchanged information with core gateways (and perhaps with each 
other) by means of the exterior gateway protocol (EGP). Routing was intended to 
be implemented as transmission down a branch of the topology tree to 
ARPANET, across ARPANET to an appropriate exit core gateway, and then out 
the branch to the destination, as illustrated in Fig. 6. A network could be con¬ 
nected to the core via several core gateways, but cross-connections between 
branches farther out were not well accommodated in the EGP design. In fact, the 
design of an exterior gateway protocol to deal with a true mesh topology was only 
begun seriously in 1988, although several proposals had been made by various 
researchers during the previous few years. 

As Internet grew (several hundred networks by 1988) and as the constituent 
networks increased in bandwidth (e.g., 10-Mbps Ethernets) the LSI-11 gateways 
were replaced by faster, more powerful devices. As of 1990, at least four compa¬ 
nies manufacture IP gateways in significant quantities: each product supports a 
variety of network interface types. 


Transition of ARPANET Operations to the 
Defense Communications Agency 

Although the sections above describe a program in internetwork research and 
development that continued into the 1980s, ARPANET merely served as a con¬ 
stituent of Internet, albeit an important one—it was not itself intended to be 
changed-srgnificantly as a result. 

FrO^We very beginning, it was assumed that ARPA would give up operating 
the nefworkeventually. The Program Plan for the network project, written in the 
middle of 1968, noted that once the experiment of building the network was 
complete, a common carrier could be requested to take over the management of 
the network of IMPs and to provide “digital message service directly to the 
individual users on a tariff basis,” permitting ARPA to end its system responsi¬ 
bility. It was hoped that this transfer could take place 3 or 4 years after the 
beginning of network development. In 1972, the federal Office of Telecommuni¬ 
cations Policy wrote a letter to ARPA strongly urging them to divest the network 
to private industry. 

By 1974, however, it was deemed more appropriate to keep ARPANET within 
the government. Therefore, a memorandum of agreement was worked out be¬ 
tween ARPA and the Defense Communications Agency (DCA) for the manage¬ 
ment of ARPANET to be transferred to DCA as of July 1, 1975, with a 6-month 
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FIG. 6 Core gateways and exterior gateways. 


phase-over period from July 1 to December 31, during which time ARPA would 
continue to help DCA with ARPANET management while DCA acclimated 
itself to the job. The memorandum also called for a detailed transition plan to be 
written; it was completed by June 1975. 

Several aspects of the memorandum of agreement and the transition plan are 
w(3£ffi'inentioning. The network was to bean operational Department of Defense 
facility used solely for government business. The concept of “ARPANET 
sptTn^FS” was invented, sponsors being users or collections of users (e.g., 
ARPA, NBS) who owned ARPANET equipment before its management was 
turned over to DCA. Ownership of the equipment was to remain with the spon¬ 
sors, and DCA was to finance the operation and maintenance of the network 
using the DCA-managed Communications Industrial Fund, which would recover 
its costs by prorating cost allocations to sponsors based on the equipment they 
used. DCA was to operate the network for 3 years until 1978, and thereafter, if 
necessary, until equivalent service could be provided on a military network. 


The Defense Data Network 

At the same time that DCA agreed to run ARPANET until 1978, a new DoD 
common-user network. Autodin II, was planned. Autodin, a DoD message- 
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switch network, was nearing the end of its useful lifetime, and Autodin II, its 
successor, was to be based on packet-switching principles, but with many addi¬ 
tional features incorporated into the packet switches. However, by the time the 
first few Autodin II switches had become operational in 1981, DCA had accumu¬ 
lated substantial experience running ARPANET and began to consider the op¬ 
tion of simply expanding ARPANET rather than deploying Autodin II. Each 
possibility had advantages and disadvantages, but after a lengthy analysis of the 
two options, the ARPANET expansion approach was selected. The actual deci¬ 
sion was to use ARPANET technology to build a Defense Data Network (DDN), 
which would subsume the ARPANET in its early instantiation. 

By the time this decision was made (1982), ARPANET comprised over 90 
IMPS (Fig. 7); roughly 60% were nonmilitary research sites and roughly 40% 
were military facilities. The military sites had been connected as a temporary 
expedient while awaiting the availability of Autodin II. With a decision to make 
these connections permanent, it was deemed inappropriate by DCA for their 
traffic to be so closely intermingled with research traffic, or to pass through 
nonmilitary institutions as a matter of course. Therefore, DDN planning called 
for a restructuring of the existing ARPANET into two independent networks. 
One of these could retain the ARPANET name and would provide service to 
researchers. The second was called MILNET and provided service for nonclassi- 
fied operational DoD traffic. (Additionally, DDN includes other independent 
networks of the same technology that carry classified traffic.) 

ARPANET and MILNET are interconnected by special IP gateways called 
mailbridges. These devices can function as normal IP gateways or, upon com¬ 
mand from a network operations center, can restrict traffic according to a num¬ 
ber of criteria, including source address, destination address, and TCP protocol 
identifier. The idea is that during times of heavy MILNET traffic, the 
mailbridges can be set to prohibit ARPANET-originated traffic from entering 
MILNET, while still allowing military traffic to use ARPANET connectivity. 


ARPANET as an Internet Backbone 

In 1968rwhen ARPANET construction began, microcomputers did not exist and 
minicemgfiters were rare. An entire research facility or university had only a few 
mainframe-supporting research. When it existed at all, “high-speed communica¬ 
tion” from computer to computer generally meant 2.4 or 9.6 Kbps. User termi¬ 
nals were almost exclusively the Teletype Model 33 (110 baud) and the IBM 2741 
(134.5 baud). The ARPANET design was aimed at this environment. An IMP, 
with its four host ports, could connect to all the research computers at one 
institution. A TIP could support all the terminal bandwidth at an institution. 
The 50-Kbps IMP-to-IMP links provided more bandwidth between institutions 
than was typically available within a single institution. 

By the mid-1980s, however, most research institutions had internal communi¬ 
cation at least equal to the Ethernet rate of 10 Mbps. The microprocessor had 
swept away the dumb terminal entirely, replacing it either with a personal com¬ 
puter that could, as a sideline, do terminal emulation (at 9.6 or 19.2 Kbps), or 
with powerful workstations, each of which included the TCP/IP protocols and 
acted as a host in its own right. In this environment, a research institution ran its 
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own autonomous network, and connected a single IP gateway to its ARPANET 
IMP. The ARPANET was no longer providing service to individual hosts; it was 
instead functioning as the Internet backbone, providing service between 
gateways. 

Indeed, during a typical measurement period in June 1988, over 50% of the 
active ARPANET hosts were gateways, and they accounted for over 80% of the 
traffic. Of course, with the same 50-Kbps IMP-to-IMP circuits first employed in 
1969, the ARPANET was no longer the fastest link in the communication path 
but rather was among the slowest. 


The Next Generation 

The National Science Foundation Networks 

By the late 1970s, it had become obvious that a major impact of ARPANET was 
the way it facilitated interaction among ARPA-sponsored researchers, by allow¬ 
ing the rapid dissemination of ideas via electronic mail and by supporting collab¬ 
orative research and authorship through the transfer of computer programs and 
text files. Perhaps the first people to notice this impact were computer scientists 
at the large majority of educational institutions that did not have ARPA con¬ 
tracts. They petitioned the National Science Foundation (NSF) to fund the estab¬ 
lishment of a network for all computer scientists. 

The resulting network, the Computer Science Network (CSNET) (21), was 
started with NSF funding, but with the understanding that it would become self- 
supporting within 3 years. CSNET provided several levels of service: ARPANET 
access under a cooperative agreement negotiated between NSF and ARPA; com¬ 
munication with the CSNET central site via public packet networks (initially 
Telenet); and mail distribution/retrieval via dialed telephone links (PhoneNet). 

Not long after the establishment of CSNET, the remainder of the scientific 
community with ties to NSF began to request similar network support services, 
especially for the physical sciences. Many of the groups requesting such services 
were urged to use the mechanisms already available to the computer scientists on 
their owiCcampuses who were connected to CSNET. Thus the meaning of the 
“CS” iffiCSiNET began to change from “computer science” to “computer and 
science.T^T^-; ■' 

In early 1984, NSF set up the Office of Advanced Scientific Computing 
(OASC) to provide access to supercomputers for large numbers of physical scien¬ 
tists. OASC immediately initiated programs both for the establishment of super¬ 
computer centers and for communication network access to those centers. NSF 
combined the many networking themes that had been developing during the 
previous decade —campus local-area networks, the widespread implementation 
of IP, the transition of the ARPANET to a “backbone,” the pressure from 
scientists for networking, and the supercomputer initiative —into a new vision of 
national research networking as a three-level hierarchy. Campuses would take 
responsibility for their own internal networking needs. Campuses in a given 
geographic area would be attached to a regional network of gateways intercon¬ 
nected by leased lines. The regional networks, plus six supercomputer centers, 
would be interconnected by the NSF network, NSFNET (22), a backbone that 
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would use Tl-rate (1.544-Mbps) circuits in the late 1980s and move up to T3-rate 
(45-Mbps) circuits in the early 1990s. The regional networks might require NSF 
funding at the start but would soon become self-supporting in the same manner 
as CSNET, whereas NSFNET could begin to consider charging the regionals for 
service only after they were on solid financial footing. 

In November 1987, a consortium of Merit, Inc., IBM, and MCI was selected 
to install and operate the TI version of NSFNET, and the network became 
operational in .luly 1988. With the beginning of NSFNET operation, the 
ARFANEl' was no longer the primary backbone of liueruet and the reseaich 
community. In recognition of this status change, DARPA requested that DCA 
remove several ARPANET IMPs and circuits in April 1988, and announced its 
intention to have them all removed within 3 years. 


Interagency Cooperation 

Thus far we have focused our attention on the ARPA groundbreaking network 
initiatives and on the NSF activities supporting the wider U.S. research commu¬ 
nity. In August 1986, as a result of the growing understanding of the national 
importance of networking, the Ninety-ninth Congress directed the federal Office 
of Science and Technology Policy (OSTP) to convene a group to study the 
computer networking requirements of U.S. scientists, engineers, and researchers. 
OSTP called on the Federal Consultative Committee on Science, Engineering 
and Technology (FCCSET) to address the need for new and better networking 
technologies. The FCCSET Committee on Computer Research and Applications 
included representatives from all of the major federal agencies involved in com¬ 
puter research; one of its three subcommittees was devoted to computer network¬ 
ing and digital communications. 

The FCCSET committee was asked to deliver its reports to OSTP by August 
1987. Their report (23) presented a comprehensive look at the current state of 
computer resources, including computer networks. It analyzed the need for addi¬ 
tional resources and new technologies to support them and it also addressed the 
technical problems that must be solved to arrive at the “gigabit-per-second net- 
-wwk” that the committee recommended be established by the early part of the 
century. The report recommended establishing a coordinated research pro- 
-gram,.Involving government, industry, and universities, to provide this “national 
research network,” which would be implemented in three phases. 

In Phase One, lasting 2 years, existing agency networks would be intercon¬ 
nected and upgraded. Common protocol standards would be adopted and trans¬ 
mission facilities shared. The goal of the Phase Two program (1991-1996) would 
be to create a 45-Mbps nationwide trunk capable of delivering as much as 1.5 
Mbps to 200-300 research facilities. Development in this phase would focus on 
gateways, routers, and switches capable of handling the projected speeds, and on 
new network protocols and architectures. 

In Phase Three, the goals are much more ambitious. The committee called 
for a network that could deliver 1.5-Mbps Service to “every research facility in the 
U.S.,” with 1-3 gigabit-per-second service to selected sites. This phase was pre¬ 
dicted to require 10 years of research and development to design and build the 
hardware and software that could operate such a large network. 
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In order to coordinate their efforts to implement these recommendations, the 
following five U.S. government agencies have formed an informal Federal Re¬ 
search Internet Coordinating Committee (FRICC) (24); the National Aeronau¬ 
tics and Space Administration (NASA); the Department of Energy (DOE); the 
Department of Health and Human Services (DHHS); DARPA; and NSF. The 
FRICC will serve as a forum in which the agencies’ network needs and plans can 
be discussed and, it is hoped, combined. One of the initial plans of the FRICC is 
to have its members cooperate in the procurement of a 45-Mbps communication 
“pipe,” the Research Internet Backbone (RIB), across the United States. It will be 
multiplexed into Tl-rate channels for the use of individual FRICC members. 
NSF is the FRICC member taking the lead in the RIB procurement activity. 

A second FRICC action has been the selection of the Corporation for Na¬ 
tional Research Initiatives (NRI), a not-for-profit corporation headed by Robert 
Kahn and Vinton Cerf, to organize a research program for developing a national 
network operating at data rates in excess of 1 gigabit per second (10’ bps). NSF is 
also the FRICC member taking the contractual lead in this action, although 
funding is expected from other FRICC members as well. NRI issued a request for 
research ideas late in 1988, and selected promising activities for initial funding 
during 1989. 


The Defense Research Internet 

As previously noted, DARPA took the first steps toward dismantling ARPANET 
in April 1988, with the announced intention of completing the job within 3 
years. In 1988, the ARPANET still provided communications services directly to 
almost 100 hosts. These hosts are expected to move to regional networks, and to 
make this possible, DARPA joined NSF to help get regional networks established 
in areas where they did not exist in 1988. 

As we have already described, however, the primary function of ARPANET 
in 1988 was as a “backbone” of Internet. This function is intended to be taken 
over by the Defense Research Internet (DRI), which will be a backbone oriented 
toward^coaimunications research. The circuits for the DRI will be derived from 
the Rljl^anhed by the FRICC. Gateways based on existing products augmented 
to meeusftecific DoD needs will provide access to the DRI. DARPA and the 
Rome Air Development Center announced the award of development contracts 
for these gateways, called Research Internet Gateways (RIGs), to three contrac¬ 
tors in early 1989, for delivery in about a year. As these RIGs and the DRI come 
online, the ARPANET will finally have come to an end. 


Impact and Influence 

Government and Other Networks 

An important part of the original Program Plan for ARPANET was technology 
transfer. It stated that 
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The transfer of interactive computer network technology will occur in three forms; (1) 
Dissemination of techniques and experimental results through the open scientific and 
technical literature, (2) Through the common carriers or other commercial organiza¬ 
tions concerned with data transfer and dissemination, and (3) Through the military 
command and control centers for which the national Military Command System 
Support Center in the Pentagon serves as the focal point. 

Perhaps ARPANET’S greatest success has been in technology transfer. 

Because ARPANET development was an unclassified efforl, implemented for 
the most part by academicians and researchers, numerous papers were written 
about ARPANET during the first several years. Two key sets of papers were 
presented in sessions at the AFIPS 1970 Spring Joint Computer Conference (25) 
and the AFIPS 1972 Spring Joint Computer Conference (26). Both these sessions 
were organized by AREA, and the two sets of five papers each were specially 
bound in ARPA-provided covers and distributed widely. In 1975, AREA commis¬ 
sioned Becker and Hayes, Inc. of Los Angeles, California, to prepare a bibliogra¬ 
phy of publications related to ARPANET (27). This bibliography lists 561 rele¬ 
vant documents and includes a subject index. The National Bureau of Standards 
also prepared a bibliography (28) on computer communications that includes 
hundreds of ARPANET-related publications. 

In addition to the many papers and presentations that have been given on 
ARPANET, significant demonstrations of the technology have taken place. The 
biggest of these was at the First International Conference on Computer Commu¬ 
nications held in Washington, D.C., in 1972 (29). Standard 50-Kbps circuits 
connected existing network sites to the conference site at the Washington Hilton 
Hotel and an ARPANET TIP was set up in a demonstration room in the hotel 
for the duration of the conference. Manufacturers of all manner of computer 
terminals were invited to connect their terminals to the demonstration TIP. Each 
day throughout the conference individuals used the manufacturer-provided ter¬ 
minals to demonstrate the use of programs on ARPANET hosts. A 20- or 30-min 
motion picture about ARPANET and the promise of computer communications 
also was shown at the conference. The demonstration itself was a spectacular 
success; everything worked amazingly well, and many visitors remarked that 
ARPANET technology “really is real.” They carried this impression home with 

T—,^he-effects of ARPANET and its packet-switching technology on the aca¬ 
demic community are illustrated clearly by the development of CSNET and 
NSFNET in response to the perceptions of computer scientists and physical 
scientists that networks had become an essential part of the infrastructure sup¬ 
porting research. These perceptions arose in part from the published literature, 
but more importantly from observing the effect that networking had on col¬ 
leagues who had network access. 

The ARPANET also has had a significant effect on the development of LAN 
technology. For example, Ethernet (or its successor IEEE 803.2) is a high-speed 
LAN that uses packet technology. As of 1990, Ethernet is probably the most 
widely implemented LAN technology. It was invented by Robert Metcalfe who, 
as a graduate student, was a participant in the design of ARPANET, packet 
radio, and packet satellite protocols and was clearly influenced by that experi- 
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ence (30). Similarly, a token-ring LAN technology that probably influenced the 
IBM token-ring design (and, therefore, IEEE 802.5) was developed at MIT by 
some of the same people who were involved with MIT’s connection to the 
ARPANET. 

A second mode of technology transfer was through the actions of the com¬ 
mon carriers. In the United States, the established carriers have been extremely 
slow to recognize a need for packet technology; however, specialized carriers such 
as Telenet Communications Corp. and Tymnet Inc. began offering packet ser¬ 
vices in about 1974. Outside the United States, the established carriers moved 
rapidly; by 1978, packet services were planned or were available in Canada, 
France, Japan, Spain, and the United Kingdom. The International Telegraph 
and Telephone Consultative Committee (CCITT), a standards body for the 
world’s carriers that functions under the auspices of the United Nations, speci¬ 
fied a standard host-to-packet-switch interface in 1976. This standard, which is 
known as Recommendation X.25, provides for the establishment of “virtual 
circuits” through the public packet networks. The networks provide for the 
reliable, sequenced transfer of packets over each virtual circuit; thus, public 
packet network design stands in sharp contrast to Internet and IP philosophy. 
Nevertheless, it closely follows the level of service provided by the ARPANET 
IMPS. ARPANET influence is clear here as well. 

Finally, ARPA envisioned technology transfer to the military, especially 
through, the command and control centers. Because ARPANET served as the 
foundation for DON, as discussed earlier, this mode of technology transfer was 
also clearly successful. In addition to the ARPANET and MILNET components 
of DON, some smaller networks of similar technology carry classified traffic. 


Products and Standards 

The preceding section, in discussing the transfer of ARPANET technology to the 
common carriers, mentioned CCITT’s development of Recommendation X.25 
as the standard for connecting a host computer and a packet network. The 
influenc e of ARPANET is clear: at the time the work on this recommendation 
began jtaofher significant operational packet networks existed. CUITT adopted 
Reconi^^dations X.3, X.28, and X.29 2 years later in 1978 as the standards for 
packet askimbler/disassemblers (PADs), the public data network equivalent of 
the ARPANET TIP. Here again, the influence of ARPANET with its Tfelenet 
protocol and TIP system is obvious. 

We have also noted above that the virtual circuits of X.25 were quite different 
in orientation from the datagram gateway concepts being developed in 
ARPANET and in the INWG in 1976, when X.25 was adopted by CCITT. 
Therefore, there was considerable support from INWG members (through their 
national standards bodies) for the 1978 decision of the International Organiza¬ 
tion for Standardization (ISO) to begin developing a “Reference Vlodel” for 
“Open Systems Interconnection” (OSI). The Reference .Model would address the 
entire set of protocols needed to permit autonomous systems to communicate, as 
had been done in the ARPANET NWG and in the INWG; it would not restrict 
itself to a carrier-oriented viewpoint as did CCITT. In the process, many of the 
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INWG participants hoped, the international standardization of a datagram- 
based communication subsystem would take place. 

The United States is represented in ISO On this area of standardization) by 
ANSI —the American National Standards Institute. The U.S. government has 
been represented in the ANSI work on OSI primarily by the National Institute of 
Science and Technology (NIST) (formerly the National Bureau of Standards, or 
NBS). After studying the diverse needs of the government, NBS proposed TCP 
as an OSI transport layer standard and IP as a network layer standard. Although 
neither of these proposals survived the standardization process entirely unmodi¬ 
fied, it is fair to say that the ISO “Connectionless Network Protocol” (CLNP) is 
a direct descendant of IP, and the ISO “Transport Protocol —Class 4” (TP4) is 
similarly a direct descendant of TCP. The U.S. government formally accepted 
these ISO protocol standards in 1988 as the GOSIP (government OSI profiles) 
Federal Information Processing Standard. Here the ARPANET and Internet 
influence is not so clear—in fact some observers deny it on the grounds that “TP4 
will replace TCP” —but we believe that the influence is strong. 

Another area in which ARPANET/Internet has influenced international stan¬ 
dards is electronic mail. Electronic mail is sometimes seen as the primary use of 
Internet, and its pervasive value to researchers has led to the demands for other 
networks, such as CSNET and BITNET. In 1979, researchers interested in devel¬ 
oping a worldwide electronic-mail system for scientists formed a working group, 
under the auspices of the International Federation for Information Processing, 
to exchange and develop their ideas. Through its position papers and the influ¬ 
ence of its individual members, this group has had a substantial impact on the 
message-handling system (MHS) standards developed jointly by CCITT and 
ISO. (In CCITT, these standards are known as the X.400 Series Recommenda¬ 
tions.) 

Finally, ARPANET/Internet has had a clear influence on the commercial 
organizations whose products conform to the Internet specifications and thus 
can be purchased and “plugged in” to the Internet. For example, companies like 
BBN, Cisco, and Proteon build and sell IP gateways. Companies such as Bridge 
Communications, Encore Computers, and Spider Systems build Internet termi¬ 
nal servers that run IP, TCP, and Telnet protocols. Companies such as FTP 
SSEware, Network Solutions, and The Wollongong Group sell software pack- 
^5g« that implement Internet protocols for various popular computers and oper- 
Ttmg-systems. In addition, computer makers such as SUN Microsystems have 
decided to ship Internet protocol implementations with their computers to insure 
that Internet access will be easy for their customers. 
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